Modern-day computerized devices provide for multiple processing units that allow concurrent execution of software processes. As an example, software execution environments such as most operating systems and the Java™ Virtual Machine allow concurrent execution of sequences of instructions such as sections of code from the same or from different application programs. The sections of code or concurrently operable sequences of instructions are often generally referred to herein as threads. Threads can be separate processes or segments of code of the same or different applications. Because threads can concurrently execute with each other in such computerized devices on the same or on different processing units, situations can arise in which two threads contend for access to a common or shared resource. As an example, two software threads might require access to a shared memory location in order to perform communications with each other (e.g., in a mailbox fashion by placing data into a shared memory area for receipt by the other thread). In such cases, computer system designers have developed several conventional mechanisms that allow each thread to engage in a mutual exclusion or synchronization protocol to allow or provide synchronized access to the resource (i.e., the memory location in this example).
Conventional contention management or synchronization mechanisms provide for an ability to prevent, avoid or recover from the inopportune interleavings of concurrent thread operations. Such inopportune interleavings are commonly called “races” or race conditions. Mutual exclusion is a special case of synchronization where at most one a single thread is permitted access to protected code or data.
A conventional Java Virtual Machine (JVM) provides a mechanism referred to as Java monitors [JVM97] by which threads running application code may participate in a mutual exclusion protocol. Generally, a monitor is either locked (i.e., owned) or unlocked (i.e., free), and only one thread may own the monitor at any one time. Only after acquiring ownership of a monitor may a thread enter a critical section of code (synchronized block) protected by the monitor. If a thread attempts to lock a monitor and the monitor is in an unlocked state, the thread immediately gains ownership of the monitor. If a subsequent thread attempts to gain ownership of the monitor while the monitor is locked, that subsequent thread will not be permitted to proceed into (i.e., execute) the critical section of code until the owning thread releases the lock on the monitor and the subsequent thread manages to gain (or is granted) exclusive ownership of the monitor. Thus to “enter” a monitor means a thread has acquired exclusive ownership of the monitor and enters and begins execution of the associated critical section of code protected by the monitor. Likewise, to “exit” a monitor means to release ownership of the monitor and exit execution of the critical section. A thread that has locked a monitor now “owns” that monitor.